Advances in technology over the years have greatly increased the number of computer software applications available to meet the needs of computer users. This demand for the increased number of applications and data management have enabled an evolution in computing environments to extend to modern architectures that we use today. One example would be distributed computer processing, which uses “data exchange” to expand computing from a single machine to multiple machines across computer networks.
Advances in development/evolution of software have not kept pace with the diverse needs of users. While there are definite benefits to current software architectures, their complexity and structure can make it difficult to freely and securely exchange data with each other. A common frustration is entering data into one application and finding that it cannot be shared with another application. The amount of data entered into these applications by users has increased in complexity, and grown exponentially. This leads to re-entering of data, copying/pasting, or importing data that takes a lot of time, can introduce errors, or data corruption and integrity issues. This lack of communication between applications has become a major problem given the vast amount of data that users generate and need to access and analyze.
Not surprisingly, the evolution of computing environments continues to be based on more complex computer architectures. The sheer complexity of the computing environments have further hindered interoperability with limited or no data exchange between applications from different architectures.
“Data exchange” refers to the taking of data structured according to a source computer application and transforming it into data structured according to a target computer application. By using “data exchange,” the evolution in computing environments served to meet even more needs of even more computer users.
Now a description is provided of different software architectures and disadvantages of some of the architectures. This is followed by a discussion of the disadvantages of the architectures affecting the data exchange between applications created under the different architectures.
Initially, application developers implemented 1-tier computer applications according to 1-tier architecture by using the “monolithic” computing model. Each 1-tier application in its entirety consisted of one software module. Therefore, each 1-tier application was self-contained, resided on one machine, and operated independently. Accordingly, users did not easily exchange data between applications running on different machines.
Later, application developers implemented 2-tier computer applications according to 2-tier architecture by using the “client-server” model. Each 2-tier application included two software modules, the “client” and “server.” Each application could theoretically reside on the same machine. More typical however, 2-tier applications were distributed across one or more networks, each client residing on a different machine from its counter-part server. However, data exchange in 2-tier applications did not reach beyond the client-server application nor beyond the machines on which the application resided. Accordingly, user-benefit from data exchange was limited.
Even later, application developers implemented multi-tier applications according to an architecture having three basic tiers, the “interface-tier,” the “logic-tier” and the “data-tier.” Typically, the “interface-tier” or upper-tier included a single software module residing on a client machine; the “logic-tier” or middle-tier included one or more logic-modules each residing on a logic-machine; and, the “data-tier” or lower-tier included one software module residing on a database-machine. In this, the multi-tier application simultaneously resided on different machines. Therefore, multi-tier applications were considered distributed computer processing. However, data exchange in the multi-tier application did not reach beyond the multi-tier application nor the machines on which the multi-tier application resided. Accordingly, user benefit from data exchange is also limited.
Service-oriented architecture (SOA), a more recent software architecture, was designed to facilitate data exchange between disparate systems. SOA defines and provisions the IT infrastructure with a system and method to allow different applications to exchange data and participate in business processes. SOA uses messaging and generic interfaces to communicate between dissimilar systems. SOA separates functions into distinct units (services), which are distributable over networks, combinable and reusable to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA works well for exchanging data between applications programmed under a particular SOA, such as a .Net platform. However, data exchange issues are still present when communicating with applications created under a different SOA platforms.
From an end user's perspective, these current architectures have constraints, because control of the applications is still in the vendor's or developer's hands. While functionality (as in tasks) may be changed to user's needs to a limited extent, the coding (which represents true control) is still with the vendor or developer. Conflicts on agreeing to a universal standard or universal data structure leads back to the situation where there are individual standards for each vendor. Interoperability between applications using the architectures discussed above still depends on agreement among vendors. Therefore, end-users are still tied (locked-in) into the application choices made by the vendor.
For example, a user may desire to exchange contact or calendar information between two different customer relationship management (CRM) applications made by two different vendors and possibly programmed under two different software architectures. For example, a user may be using a web-based CRM application, and a personal computer (PC)-based CRM application that may have complementing features. In order to provide data exchange between the two programs, such as for synchronizing the contact and calendar information, code would have to be written that converts contact and calendar data from a data format used by the web-based CRM to a data format used by the PC-based CRM and vice versa. If the user has multiple CRM applications, this specialized code must be provided for each pair of applications that need data exchange. This becomes quite a cumbersome, as well as costly, task. In fact, the specialized code is usually written by a vendor so that users would migrate off of a competitor's platform. Normally code is not written to keep both applications in use, and vendors' in general are not open to assisting users if they believe that the user will be moving their data to another vendor.
End users are not the only ones to experience frustration because of disparate architectures and lack of interoperability between applications created under different architectures; computer system administrators and software application developers suffer as well. As a computer systems become obsolete, or unsupported, and users' still need features offered by the legacy application. One technique used is to export delineated files from the legacy application, and then import them into the newer one. Normally, data from legacy systems are exported as a one-way/one-time event, and lack the ability to exchange data with newer applications continuously. In addition, importing data into and exporting data outside a particular product's suite of applications using, for example, comma-delineated files can be inconsistent between different architectures (most likely due to mixed encoding schemes).
Thus, due to (1) the lack of interoperability between the non-obsolete already-employed computing power and the already-available expanded and increased computing power, (2) the lack of interoperability between applications created under different software architectures; and (3) the resulting financial pressure to extend the life-cycle of legacy computer systems and applications and to more fully realize investments therein, banking, military, government, business, and end users are all faced with a choice, of selecting one application over another. This may result in either prematurely retiring perfectly usable applications, loss of convenience, and other disadvantages. This choice will persist at least until there is interoperability between software applications.